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Context Oriented Programming (COP) concerns the ability of programs to adapt to changes in their 
running environment. A number of programming languages endowed with COP constructs and fea- 
tures have been developed. However, some foundational issues remain unclear. This paper proposes 
adopting static analysis techniques to reason on and predict how programs adapt their behaviour We 
introduce a core functional language, ContextML, equipped with COP primitives for manipulating 
contexts and for programming behavioural variations. In particular, we specify the dispatching mech- 
anism, used to select the program fragments to be executed in the current active context. Besides the 
dynamic semantics we present an annotated type system. It guarantees that the well-typed programs 
adapt to any context, i.e. the dispatching mechanism always succeeds at run-time. 

1 Introduction 

Computers increasingly pervade our everyday life, pushed by the great improvements of hardware sys- 
tems and by the growing usage of digital information. 

On the one side, computer devices surround people in different shapes and sizes in a highly dis- 
tributed manner Devices are often interconnected, can interact each others and share resources. Pro- 
grams themselves are resources being invokable remote services or downloadable code. 

On the other side, processing the great quantity of information generated and consumed by devices 
leads to a paradigm, where most of the computation and of the storage is demanded to specific, powerful 
remote entities. This is the case of Cloud or Grid systems, made of heterogeneous nodes, possibly 
distributed in a wide-area. 

This new setting puts software system into a highly-dynamic environment where services, resources 
and hardware components appear, mutate, move and disappear. This calls for a a great shift of program- 
ming paradigm. In particular, there is a growing interest in the design and development of applications 
that are aware of their working environment and are adaptive, i.e. capable to adapt to different situations. 

Context-Oriented Programming (C0P)[8 | has been recently proposed to tackle such an issues. COP 
makes available language primitives to express context-dependent behaviour (called behavioural varia- 
tion) in a modular fashion. Behavioural variations are chunks of behaviour that modify the execution of 
a computational system depending on the current working environment. Layers are the linguistic mech- 
anism that enable the programmer to group variations. Layers can be activated in arbitrary places of the 
code with appropriate primitives. Each layer activation has its own scope; activated layers are piled up 
into a stack that is called context. Therefore, the actual behaviour of a COP program is carried out by a 
dispatching procedure that selects the program fragments to be executed depending on the context. 

Most of the research efforts in this field are focused on the concrete implementation details and only 
a few papers [1 A \ investigated basic foundational issues. We briefly discuss them in Section 3. 

Our work aims at contributing to the foundations of COP programming languages. We introduce a 
core calculus (ContextML) with a precise semantic description of the adaptivity constructs. 
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To illustrate the novel features of ContextML we resort to a running example. Consider a program 
embedded in a mobile device, the behaviour of which depends on the active profile of its battery. We 
assume that the battery level has two profiles, the power saving mode and the performance one. These 
profiles are represented at code level as two different layers: PowerSavingMode and Perf ormanceMode. 
The function getBatteryProf ile, described below, queries the sensor (batSensor) and returns the 
layer describing the current active profile depending on a threshold value: 

AgetBatteryProf iie() ^if (batSensor() > threshold) then 

Perf ormcinceMode 

else 

PowerSavingMode 

Layers are expressible values, hence they can be produced as results of function calls. The construct 
with(ei) in 62 activates the layer obtained evaluating ei and delimits its activation scope to the inner ex- 
pression €2- For instance, in the code below, the layer obtained as result of the call getBatteryProf ile() 
is active throughout the execution of the inner expression. 

with(getBatteryProf ile()) in 

PowerSavingMode. doSomeThing(), 
Perf ormanceMode. doSomeThingElse() 

In the inner expression, the layered expression is defined by cases that specify the context-dependent 
behavioural variation considered. 

Note that if the programmer neglects a case for the profile of the battery, e.g. OnDemandMode, then 
the program throws a run-time error being unable to adapt to the context. We propose to detect these 
undesired behaviour by adopting static analysis techniques. To this aim we extend the ML type system in 
order to guarantee that well-typed programs are always capable to react to their changing environment, 
i.e. the dispatching procedure always succeeds at run-time. 

2 ContextML: a context-oriented ML core 

ContextML is a purely functional fragment of ML extended with COP primitives. In ContextML the 
context is explicit and is part of the run-time environment. The language is endowed with primitives to 
manipulate the context and to specify behavioural variation of expressions, depending on the context in 
which the program is evaluated. The structural operational semantics and the type system of ContextML 
follow. 

Dynamic Semantics Let N be the set of naturals, Ide a set of identifiers, LayerNames a set of layer 
names, then the syntax of ContextML is defined by the following grammar: 

nSN x,/elde L G LayerNames 
v,vi,v' ::= n \ L \ Xf X => e 

e,e\,e' ■.■.= v\ x\ eie2 | letx = ei in 62 \ei op 62 | if tlienei else €2 \ with(ei) ine2 | lexp 
lexp ■.■.= L.e I L.ejexp 

The novelties with respect to ML are layers as expressible values; the with construct for activating 
layers; and the layered expressions (lexp). Recall that a context C is a stack of active layers. We denote 
with L :: C the pushing of layer L on C and with [Li,...,L„]a context with n elements whose top is Li. 
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withi 



L::Che-^e' 



with3 



C h with(L) in e — s> with(L) in e' 



lexp 



WltnT ; — ^ 

C h with(L) in V ^ V 

3k. k = mm{j \ 3v.L'j = L,.}AL[ = U 



C h with(e) in e\ — s> with(e') in e\ 



Figure 1 : ContextML semantics. 



The semantics is only defined for closed expression and is characterised by judgements having the 
form C \- e ^ e' meaning that in context C the closed expression e reduces to e' in one evaluation 
step. In Figure [Uwe only show the semantic rules (withi),(with2),(with3),(lexp) that deal with the new 
constructs, the others are inherited from the standard ML. We briefly comment on the new ones only. 
Rules for with(ei) in 62 evaluate 62 in the context extended by the layer obtained evaluating e^. When a 
layered expression Li .ei , . . . ,L„.en has to be evaluated (rule lexp), the context of evaluation is inspected 
top-down (dispatch mechanism). When a layer in the context matches one of the L,, the corresponding 
expression e,- is evaluated. If no layer matches then the computation gets stuck. 

Type system We introduce a monomorphic type system for ContextML which ensures that the dispatch 
mechanism always succeeds at run-time for well-typed expressions. 

Our type system is characterised by typing judgements of the form (r;C) \- e : t. This means that in 
"in the type environment F and in the context C expression e has type t". 

Types are integers, layers and functions. 



We annotate types with sets of layer names , i/a for analysis reason. In ly^ , over-approximates the 

layers that an expression can be reduced to at run-time. In Ti T2, V'^ over-approximates the layers that 
must be active in the context during the application of the function (precondition of the function). 
Back to our example, the type of the function getBatteryProf ile will be the following: 



The intuition is that the function returns a layer in the set {PowerSavingMode,Perf ormanceMode}. 
The function has no preconditions, i.e. it can be applied in any context. 

Our typing rules are in Figure |2] Since types are annotated, the type system contains rules dealing 
with the subtyping. The rules (Sint), (Sly), (Sfun) have judgements of the form Zi < T2 (Ti is a subtype 
of T2). Furthermore, we assume that annotations are ordered by set-inclusion and that |C| is the set of 
active layers in a context C. 

By rule (Sly) a layer type ty^ is a subtype ty^i if and only if the annotation is a subset of (p'. Rule 

(Sfun) is subtyping rule for functional types. As usual Ti ^ T2 is contravariant in Ti but co variant in 
and T2- 

Rule (Tly) asserts that the type of a layer L is ly annotated with the singleton set {L}. In rule (Tfun) 
we guess a type for the bound variable, for the function / and determine the type of the body under these 
additional assumptions and in a guessed context C'. Implicitly, we require that the guess of a type for / 
matches that of the resulting function. Additionally we require that the resulting type is annotated with a 
precondition that includes the layers in C'. 



t,Ti,t' ::= int | /j^ | Ti — > T2 ^ p(LayerNames) 



unit — )• /^{PowerSavingMode.Perf 



ormanceMode} ■ 
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C 0' 

(Sint)^-— — (Sly) 



int < int ly^ < ly^i 

t[<Ti T2 < r C V/' 
(Sfun) 

Tl — > T2 < Tj — !• 
(Tint)——— ; (Tly) 



T;C) \- n : int (F; C) h L : /y{L} 

(r;C)he:T' t' < T r(x) = T if xedomCr) 

(Tsub)^ ^ = (TVar)- ^ ' 



(r;C)he:T (r;C)hx:T 

^ {r,x:Tuf-Ti^T2;C')^e:T2 
(Tfun) — 

{T;C)hXfX^e:xi ^ Ti 

(r;C) h e\ : int (r;C) h e2 '■ int 
(Top) 



(Tlet) 



(r;C) h ei op €2 '■ int 
r;C)hei:Ti (r,x : Ti,C) h : T2 



(Tif)- 



(Twith)- 



(F; C) h let A- = ei in e2 ■ ^2 
r;C)heo:/«f (r;C)l-ei:T (r;C)he2:T 
(r;C) l- if eo then ei else e2 : t 
(r;C} h: ei : VL' G 0.(r;L' :: C) h 62 : T 



(Tlexp) 
(Tapp) 



(r;C) h with(ei) ine2 : T 

V/.(r;C) he;: T Lj G |C| V • • • VL„ £ |C| 



(r;C) |-Li.ei,...,L„.e„ : T 
(r;C) h : Ti ^ T2 (r;C) h ^2 : Ti C |C| 



(r;C) I- eie2 : T2 
Figure 2: ContextML type system 



Rule (Twith) establishes that an expression with has type T, provided the type for ei is ly^ (recall 
that is a set of layers) and 62 has type T in the context C extended by the layers in (p. By (Tlexp) 
the type of a layered expression is T, provided that each sub-expression has type T and that at least 
one among the layers Li, . . .L„ is active in the context C. This requirement is the key to ensure that the 
dispatch mechanism always succeeds at run-time. Notably, when evaluating a layered expression one of 
the mentioned layers will be active in the current context. 

Back to our example, the expression provided is well-typed as witnessed in Figure [3] The type of 
getBatteryProf ile ensures that one of the two layers PowerSavingMode or Perf ormanceMode is 
returned. One among them is required to be active so to evaluate the layered expression. Hence, the 
(Twith) rule can guarantee that the whole expression is never stuck at run-time. 

Rule (Tapp) is almost standard and reveals the mechanism of function precondition. The application 
gets a type if only if the layers in the precondition are active in the current context C. To better explain 
how preconditions work, consider the example in Figure 5] There the function Xf x ^ L\.0 is shown 

having type int int. This means that Li must be active in the context of activation of the function. 

The remaining rules are standard and we do not comment on them for brevity. 

Our type system guarantees not only that functional types are correctly used, but also that the eval- 
uation of a layered expression never gets stuck. The following lemmata prove that our type system is 
sound with respect to the operational semantics: 
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(r;C') h doSomeThingO : T (r;C') h doSomeThingElse() : T 

PowerSavingMode G |C'| VPerf ormanceMode e |C' 
(Tlexp) 

(r C^ h CTlexD) 



{r;C) h: getBatteryProf ile() : />'0 ' PerformanceMode.doSomeThingElse() ' ^ {r;C")h... 

,„ „, , / „ „ PowerSavingMode. doSomeThingO, 

(r;C) h with getBatteryProfileO) in „ ^ .. , , o ■ m :t 

^ ' ^'^ Perf ormanceMode.doSomeThmgElseO 

Figure 3: The typing derivation of the running example. We assume doSomeThing,d.oSomeThingElse : 
unit T. We denote ^ = {PowerSavingMode, Perf ormanceMode};C' = PowerSavingMode :: C;C" = 
Perf ormanceMode :: C. The last rule used is (Twith). 

(r,x:-r,/:-r '^-r;C'>hLi.O:T (r,g : -r ^ -r;C> h 3 : t \C'\C\C\ 



(r;C> ^Xfx^Li.O-.T^r (r,g : -r ^ -r;C> h g3 : t 

(r;C> hletg = A/x=^Li.0ing3 : t 

Figure 4: Derivation of a function with precondition. We assume that C' = [Li], Li is active in C and, for 
typesetting convenience, we also denote t = int. 



Lemma 2.1 (Progress). Let e be a closed expression such that for some C (r;C) \- e : 1. Then either e is 
a value orC\-e^e'. 

Lemma 2.2 (Subject reduction). Let e be a closed expression, if (r;C) h e : T and C h e — > then 
(r,C)he':T 



3 Discussion 



Related work Several COP programming languages have been proposed (see e.g.ContextL [5| and 
Contexts [1]). Usually COP features are introduced within the object oriented paradigm so providing 
behavioural variations at object level. 

Most of the research efforts have mainly tackled implementation issues. To the best of our knowledge 
only few papers provide a precise semantic description. 

In 171 an extension of Featherweight Java [10] has been proposed. This calculus includes layers 
(de)activation, but layers are not expressible values. Furthermore, a static type system ensures that there 
exists a binding for each dispatched method call. This fact is based on the strong assumption that layers 
do not introduce new methods but only refine existent ones. Our type system relaxes this assumption. 

Our approach is much similar to the one of Clarke et al. |S] and the main difference is that we consider 
a functional language while llH considers an object oriented language. Featherweight Java. 



Conclusions and further work We started investigating the foundational issues of the COP paradigm 
with a calculus endowing COP primitives. We have defined a dynamic semantics that formalises the 
operational mechanisms behind these constructs. A distinguished element of our semantics is the dis- 
patching procedure, that selects the behavioural variation depending on the active context. We have also 
specified a type system guaranteeing that the dispatching mechanism always succeeds at run-time for 
well-typed expressions. 

In our current proposals, activation of layers is driven according to the flow of program execution. A 
more general approach would instead consider the asynchronous evolution of the environment. We plan 
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to investigate this issue and to fomialise event-driven changes of context. 

We also intend to refine the type system by introducing effects to represent an over-approximation of 
the evolution pattern of context shape. In doing that, techniques similar to session-types |9 1 might suggest 
us useful mechanisms. Types and effects will enhance our static analysis of programs, following the lines 
of El 13 . In particular we would like to accept or reject programs at compile time, also depending on 
non-functional requirements on the context evolution, e.g. when security policies are to be enforced upon 
context usages (for a recent proposal see [6 1). 
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